Integrated Circuit Design (ICD) or Chip Design is a branch of electronics engineering. ICD deals with encompassing the particular logic and circuit design techniques required for designing integrated circuits, or ICs. Initially, the integrated circuits contained only a few transistors. However, the number of transistors in the integrated circuits has increased dramatically since then. The term “large scale integration” (LSI) was first used to describe this theoretical concept, which further gave rise to the terms “small-scale integration” (SSI), “medium-scale integration” (MSI), “very-large-scale integration” (VLSI), and “ultra-large-scale integration” (VLSI). The development of VLSI started with hundreds of thousands of transistors in the early 1980s, and has continued beyond ten billion transistors as of now.
Modern ICs are immensely complicated. The complexity of modern IC design and market pressure for producing designs rapidly has led to the extensive use of automated design tools in process of IC designing. In short, the design of an IC using Electronic Design Automation (EDA) is the process of design, verification and testing of the instructions that the IC has to carry out.
Electronic Design Automation (EDA) and Electronic Computer-Aided Design (ECAD) is a category of tools that is used to design electronic systems such as integrated circuits as well as printed circuit boards. Designers use these tools that work together in a flow to design and analyze the entire semiconductor chips. EDA tools are essential for designing modern semiconductor chips which have billions of components. The EDA tools help chip design with programming languages that compiled them to silicon. Due to immediate result, there was a considerable increase in the complexity of the chips that could be designed, with improved access to design verification tools that are based on Logic Simulation. A chip designed using this process is easier to lay out and more likely to function correctly, since the design of the chip could be simulated more thoroughly prior to construction. Although the languages and tools have evolved, this general approach of specifying the desired behaviour in a textual programming language and letting the tools derive the detailed physical design has remained the basis of digital IC design even today.
A Simulation (or “sim”) is an attempt to model a real-life or hypothetical situation on a computer to study the working of the system. Predictions may be made about the behaviour of the system, by changing variables in the simulation. It is a tool to virtually investigate the behaviour of the system under study.
A Logic simulation is the use of simulation software for predicting the behaviour of digital circuits and Hardware Description Languages (HDL). It simulates the logic before it is built. Simulations have the advantage of providing a familiar look and feel to the user in that it is constructed from the same language and symbols used in design. Simulation is a natural way for the designer to get feedback on their design, by allowing the user to interact directly with the design. Logic simulation may be used as part of the Functional Verification process in designing hardware.
Functional verification is the process followed for verifying whether the logic design conforms to the design specification. In everyday terms, functional verification asserts whether the proposed design do what is intended. This is a complex task, and takes the majority of time and effort in most large electronic system design projects.
Hardware Description language (HDL) is a specialized computer language used for describing the structure and behaviour of electronic circuits, and most commonly, digital logic circuits. A hardware description language enables a precise, formal description of an electronic circuit which allows for the automated analysis and simulation of an electronic circuit. A hardware description language is much like a programming language such as C Programming language. HDL is a textual description language consisting of expressions, statements and control structures. One important difference between most programming languages and HDLs is that HDLs explicitly include the notion of time. The key advantage of a HDL, when used for systems design, is that it allows the behaviour of the required system to be described (modelled) and verified (simulated) before synthesis tools translate the design into real hardware (gates and wires). With time, VHDL and Verilog emerged as the dominant HDLs in the electronics industry, while older and less capable HDLs gradually disappeared. Over the years, much effort has been invested in improving HDLs. The latest iteration of Verilog, formally known as System Verilog, introduces many new features (classes, random variables, and properties/assertions) to address the growing need for better testbench randomization, design hierarchy, and reuse.
A testbench is an (often virtual) environment used to verify the correctness or soundness of a design or model. In the context of firmware or hardware engineering, a testbench refers to an environment in which the design/system/product under development is verified with the aid of software and hardware tools. The suite of verification tools is designed specifically for the design/system/product under verification. Testbench, commonly referred as verification environment (or just environment) contains a set of components such as bus functional models (BFMs), bus monitors, memory modules, and interconnect of such components with the Design Under Verification (DUV).
A simulation environment is typically composed of several types of components: The Generator generates input vectors that are used to search for anomalies that exist between the intent (specifications) and the implementation (HDL Code). Modern generators create directed-random and random stimuli that are statistically driven to verify random parts of the design. The randomness is important to achieve a high distribution over the huge space of the available input stimuli. To this end, users of these generators intentionally under-specify the requirements for the generated tests. It is the role of the generator to randomly fill this gap. This allows the generator to create inputs that reveal bugs not being searched by the user. Generators also bias the stimuli towards design corner cases to further stress the logic. Biasing and randomness serve different goals and there are trade-offs between them. As a result, different generators have a different mix of these characteristics. Since the input for the design must be valid (legal) and many targets (such as biasing) should be maintained, many generators use the constraint satisfaction problem (CSP) technique to solve the complex verification requirements. The legality of the design inputs and the biasing arsenal are modelled. The model-based generators use this model to produce the correct stimuli for the target design.
Drivers translate the stimuli produced by the generator into the actual inputs for the design under verification. Generators create inputs at a high level of abstraction, as transactions and drivers convert this input into actual design inputs as defined in the specification of the design's interface.
A Monitor converts the state of the design and its outputs to a transaction abstraction level so it can be stored in a scoreboard's database to be checked later on.
The Scoreboard/Checker validates that the contents of the scoreboard are legal. There are cases where the generator creates expected results, in addition to the inputs. In these cases, the checker must validate that the actual results match the expected ones.
An Arbitration Manager is configured to manage all the above components together.
The simulator produces the outputs of the design, based on the design's current state (the state of the flip-flops) and the injected inputs. The simulator has a description of the design net-list. This description is created by synthesizing the HDL to a low gate level net-list.
Simulation based verification is widely used to “simulate” the design, since this method scales up very easily. Stimulus is targeted to exercise each line in the HDL code. A testbench is built to functionally verify the design by providing meaningful scenarios to check that given certain input, the design performs to the specification.
The level of effort required to debug and then verify the design is proportional to the maturity of the design. That is, early in the design's life, bugs and incorrect behaviour are usually found quickly. As the design matures, the simulation requires more time and resources to run, and errors will take progressively longer to be found.
One of the most critical tasks in developing a new hardware such as Integrated Circuit (IC) chips, Field-Programmable Gate Arrays (FPGA), Application-Specific Integrated Circuits (ASIC), System On Chips (SOC) etc. is to verify them for different design/function/performance specifications. These specifications may be predefined by the customer of the chips or can be an industry standard too. Another challenge faced by the verification team of this hardware is to debug the failures (if any) that arises during the process of verification using the log file(s) and identify the root cause of the failure.
An input packet/transaction entering a Design Under Verification/System Under Verification (DUV/SUV) might take different data paths, undergo header or contents changes, get duplicated, endure different delays etc. and make it to the DUV/SUV output via different interfaces. While verifying such complex systems, it sometimes becomes very difficult and tedious to trace the flow of packet/transaction from the input to the output using the regular logs that are generated during the simulation.
For example, the steps of packet/transaction generation, injection into the DUV, testbench predictions made, output interfaces monitoring and data integrity checking might happen at different time intervals and relevant information might be routed to single/different log(s) at different time intervals. Particularly, when more and more packets/transactions are injected and in case there are any packet/transaction mismatches, the failure analysis and debugging might take significant verification effort and time in order to identify the root cause of the failure.
Currently, there is no standard way to record transaction specific stage-wise flow information for each input packet for the DUV/SUV and generate a log file from the recorded information when there is a corresponding data mismatch seen during data integrity checks or a missing DUV/SUV output packet detected. Whenever there is any packet/transaction mismatch seen/missing packet detected by a verification system/testbench, in order to understand the mismatch/error/issue, a user may have to spend a lot of effort and time for manually tracing the corresponding transaction from the testbench prediction (Scoreboard) Input to the Data Integrity Checker Input in multiple log files or at multiple places if there is just a single consolidated log file especially when there are multiple functionalities/paths/delays and complexities involved.